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A device-specific communicating between a transmitting device 
and a receiving device 

Field of the Invention 

5 The present invention relates to a system and a method for communication of data 
between a WEB server and a mobile device equipped with a browser and mobile 
Internet capabilities, such as a WAP-compliant mobile phone. The invention further 
relates to a method of dynamic, cheap and fast conversion of data between a first and 
a second format compliant to the WEB server and the device. 

10 

Background 

Primarily due to differences in data formats there are currently no means for reading 
data comprised in e.g. an HTML WEB page from most browsers in mobile devices. In 
order to access WEB page information from a WAP phone, the WEB pages has to be 
15 converted. Today the owner of a WEB page typically selects specific data from the 
WEB page that he wants to make accessible from a WAP phone. The data is then 
converted and a new data file containing the converted data is created. When a WAP 
phone customer enters the specific WEB page, it is in reality the data file containing 
the converted data that is entered. 

20 

Due to the duplication of the WEB page information, two data files having different 
content, even though they disclose the same information, have to be updated. This is 
both costly and time consuming. Moreover the risk of faults is higher given that two 
pages must provide identical information in different formats. 

25 

Currently there exist methods to convert source data, such as web pages, into a 
general or device specific formats compatible with browser applications in mobile 
devices. Existing methods, however, generally suffer from drawbacks. Some methods 
are based on fully automatic or general conversion methods, meaning that certain 

30 data formats (e.g. web pages for desktop browsers) are converted to a data format 
suitable for display in mobile devices based on totally general (not context or 
application specific) conversion rules. This method has proven to often give poor 
results, except for the simplest cases since it is currently very hard or even impossible 
for such general conversion rules to always be able to deduct what parts of specific 

35 content are relevant enough to include in the second data format- To overcome this 
limitation there are also known methods, which offer application developers to 
manually define the transformation for each context or application. While this method 
offers full flexibility it is generally time consuming and therefore expensive. 
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Summary f the Invent! n 

It is an object of the present invention to allow transfer of data from a data source to 
devices with limited processing and display capabilities. A unique method for 
conversion of data formats from source data format into device specific format, 
5 without having two different pages with the same information is presented. The 
present invention accomplishes the conversion by uniquely combining general and 
context specific conversion methods to offer conversion, which is flexible and yet 
minimizes the need for manual intervention by an application developer. 

10 Accordingly the present invention relates to a method for communicating between a 
transmitting device and a receiving device, the communication comprising conversion 
of source data in a first format as output from the transmitting device into a second 
format to be received by the receiving device. The conversion is separated into two 
steps, where the first step is based on manually created context or application specific 

15 conversion rules, defined by an application developer, resulting in an intermediate, 
device-independent, standardized format and where the second step is based on 
general, device specific, conversion rules transforming the intermediate, standardized 
intermediate format into a device-specific, second data format suitable for display in a 
mobile device, which requests the content. 

20 

Furthermore since the intermediate, standardized, data format is device-independent 
this means that the developer of the application does not have to worry about the 
characteristics of particular types of devices and the end result (after the automatic, 
second, general conversion step is applied) is still a device-specific version of the data 
25 tailored to meet the capabilities of the particular device which requests the content. 

Detailed Description of the Invention 

In the first aspect of the present invention a method for communicating between a 
transmitting device and a receiving device is disclosed, wherein the communication is 
30 initiated by a request for a data from a data source, and the communication 

comprising conversion of source data in a first format as output from the transmitting 
device into a second, device-specific format to be received by the receiving device. 
Specifically the method comprises the steps of inline: 

35 - receiving data in the first format from the server, 

- converting the source data from the first format into data in the second format 
where the conversion is separated into a two part process and is comprised of at 
least the following two separated steps 

- converting the data from the first format into an intermediate, device- 
40 independent, standardized format using content- or application-specific 
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conversion rules, manually defined for each application, relating the first 
format to the standardized, intermediate format. 
- converting the data in the intermediate, device-independent, standardized 
format into a device-specific, second format using general conversion rules 
5 relating the intermediate format to the device-specific, second format 

Optionally, if beneficial, prior to converting the source data into a standardized, 
intermediate format, the source data may be processed by a pre-processor, which 
converts the source data format into a more standardized source data format to make 
10 it more suitable for further transformation. The preprocessing step, if applied, is 

automatic and based on general conversion rules and has the sole purpose of making 
the source data more suitable for further processing. 

All of the above-mentioned conversion steps could be performed by means of a 
15 database search routine where the content of the database is the conversion rules. 
The conversion rules comprises relations between the data in the first format and data 
in the second format and could be performed over more than one conversion step by 
associating the data in the first format with conversion rules of more than one set of 
conversion rules. 

20 

If the conversion is a two-step conversion applied after preprocessing the source data, 
the preprocessing step could comprise conversion rules that convert the first format 
into a legal, standardized format by associating the data in the first format with rules 
relating to the legal, standardized format. The legal format could be a format such as 

25 XML or XHTML. The first conversion step, applied after the preprocessing step, could 
comprise conversion rules that convert the legal format into an intermediate, device- 
independent format, such as XML or XHTML, by means of context-specific conversion 
rules which relate the preprocessed legal data format with an intermediate data 
format containing all the relevant content given the context or application being 

30 defined. 

The second conversion step could comprise selection rules that convert the 
intermediate data format into a second device-specific format such as WML by 
associating the data in the intermediate format with rules relating to the second 
format. The two-step conversion has the advantage of enabling a separation between 
35 the manual selection of the relevant content of the source data and the conversion of 
that content Into a device-specific (e.g. WML) format into two separate conversion 
rule databases. 

The communication is initiated by means of parameters that are passed in as a part of 
40 the request wherein said parameters are for selection of the conversion and selection 
rules. The request for data can also concern data from more than one data source. As 
an example data may be selected based upon the technical capabilities of the device 
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or data may be selected based upon a desired reduction of the information to be 
communicated. If a user of a mobile device requests data from a WEB server, the 
parameter could comprise a list of technical features of the mobile phone, e.g. that 
colors in graphical images cannot be displayed and the amount of communicated data 
5 therefore could be reduced. If an owner of an Internet web page only wants to 
communicate certain parts of the page the parameter could comprise a list of data 
fields of the Internet home page to be converted. In that way the amount of data to 
be converted and transmitted between the communication parties could be reduced 
and the conversion could be adapted for a specific purpose. 

10 

In the present context ''Source data" can be any data external to the system, such as 
any HTML data obtained from a web server. 

The term ^'Legal, standardized format" (result of preprocessing) refers to result of 
15 converting source data (such as irregular HTML data) into a more standardized format 
for the sole purpose of making it more suitable for further processing. This typically 
involves converting irregular HTML Into xHTML or XML, an XML-based version of the 
same HTML. No content selection or device adaptation happens in this step. 

20 In the present context the term ^intermediate, device-independent, standardized 
format" refers to result of first, manual, conversion step, where this format is the 
result of applying context specific conversion rules for the purpose of selecting the 
relevant (according to the context or application being developed) content or data 
from the source data and also, to a certain extent, to format the content in such a 

25 way as too suit generic small displays and capabilities of mobile devices. The result is 
an intermediate format in XML or XHTML. It is standardized (based on a relatively 
rigid specification) so that general device-specific conversion rules can be applied to it 
to tailor the intermediate device-independent format to suit the capabilities of 
particular types of devices. 

30 

The term ''content-specific selection rules" refers to content, application or context- 
specific selection rules being selection rules that are based on knowledge of the 
particular content being transformed. An example would be to select the most 
important Information from a web page and discard the rest, i.e. it typically involves 
35 selecting only part of the source data, based on the developer's judgment regarding 
what parts of it should be accessible from a mobile device. 

In the present context the term "manually created" means that the conversions are 
created per-application by a developer having knowledge of the content being 
40 converted. 
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The term ''Device-specific" refers to device specific conversion rules are based on 
information about many different types of devices and are able to convert the 
intermediate, device-independent format into a device specific version suitable for 
display in a certain type of device. As an example when a user requests content with a 
5 WAP browser In a Nokia 7650 device, the conversion will attempt to convert the 
intermediate device-independent format into a version suitable for the capabilities of 
this particular device and browser. The request will generally contain information 
about the device and browser type and this information, in conjunction with a 
database of information about the capabilities of many types of devices, is enough to 
10 enable a general and automatic conversion of the intermediate data format into a 
device specific format. 

The term ''general rules" refers to general conversion rules, which are general in the 
sense that they don't rely on content or application specific information. I.e. it means 
15 the every type of content can be automatically converted, without any developer 
intervention, as long is it adheres to the specifications of the intermediate format. 

In an embodiment of the present invention the method includes a process where the 
20 source data is translated Into a general or legal format prior to the conversion by 
associating the data In the first format with general rules relating to the legal format 

In another embodiment of the present invention the content-specific selection rules 
25 insert content-dependent hints into the intermediate, device-independent format, 
which may be used by the general conversion rules in later steps to improve the 
quality of the general, device-specific conversion 

In the present context the term "content-dependent hints" refers to pieces of 
30 information, optionally inserted by the developer into the intermediate format, that 
will aid the device-specific, automatic and general second step to better accomplish its 
conversion. This might include Information about what data pieces belong together, 
what parts of the content are more important than others or suggestions that In one 
way or another provide the second, automatic conversion step with information 
35 regarding how it may or may not format the content when tailoring it to suite the 
needs of specific devices. Those hints are however rarely binding for the second step 
since it needs a certain degree of flexibility to be able to adapt the intermediate, 
device-independent format to a wide variety of device types with vastly different 
capabilities. 

40 

The term "device-independent format" refers to any data format, which contains all 
the relevant content (for the context or the application in question), and it might also 
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be formatted to a certain extent in a generic way. It is, however, device-independent 
in the sense that it is not Icnown what type of device or browser it will be adapted to. 
The format must therefore be generic enough to make adaptation to specific devices 
possible. Therefore, only the most general assumptions about capabilities of the 
5 requesting devices may be inherent in the intermediate format. 

In an embodiment of the present invention the general conversion from the 
intermediate, device-independent format into a device specific, second format is 
performed over more than one conversion step by associating the data in the 
10 intermediate format with general conversion rules of more than one set of conversion 
rules. The general conversion from the said intermediate format into a device specific, 
second format is performed in two conversion steps as follows: 

first converting the intermediate device-independent data format into a 
15 general version of a specific type of markup language data format 

next converting the data in said general version of a specific type of 
markup language data format into a device-specific version of a specific 
type of markup language data format 

20 Furthermore, the conversion from the legal format to the device-independent, 

intermediate format is based on transformations built using a development tool, which 
may have a graphical user interface. 

In the present context the term "general version of a specific type of markup language 
25 data format" can mean a general version of Wireless mark-up language (WML), i.e. 
WML that is generic in the sense that it makes no assumption about the type of WML 
browser, which will request it. 

The term "device-specific version of a specific type of markup language data format" 
30 mean fro example a version of WML that has been optimized or tailored for a specific 
type of WAP device/ WML browser, such as Nokia 6310 WML browser. This might 
involve making sure the WAP pages are not larger than what this type of device- 
browser combination can handle. Images larger than what a specific type of browser- 
device combination can properly display might also be made smaller or omitted from 
35 the device-specific version. 

In the present context the term ^'development tool" refers to a standalone piece of 
computer software, preferable with a graphical user interface (GUI), that will aid a 
developer of an application to define, create, test, preview and deploy his application. 
40 In particular a development tool is need to help the developer define the context- 
specific, conversion rules for his application that need to be manually created by the 
developer. 
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''Graphical user interface" is well known in the art such as any type of common GUI 
interface that will aid the developer with visual representations of the data being 
worked on. 

5 

In an embodiment of the present invention the legal format is XML and the 
intermediate, device-independent format is XML-based 

In an embodiment of the present invention the transmitting device is a database and 
10 wherein the first format is a format of that device. 

The transmitting device can serve as a receiving device and vice versa. As an example 
the transmitting device could be an Internet web server and the receiving device a 
mobile device with a WAP browser, in which case the formats could be HTML and WML 
15 respectively. In the present context the transmitting device can be selected from the 
domain of but not limited to mobile devices. 

In another embodiment of the present invention the transmitting device is a WEB 
server, wherein the first format is a source format of WEB servers. Furthermore, the 
20 receiving device is a mobile device with Internet capabilities and equipped with. a 
browser, wherein the second format is a format suitable for the browser In that 
device. In a specific embodiment of the present invention the receiving device is a 
WEB server, wherein the second format is a source format of WEB servers 

25 In the present context the term ''WEB server" refers to a server, residing on the 
Internet, capable of serving requests made in the HTTP protocol. Generally means 
serving content in HTML format but it might be other types of content as well. 

In one embodiment of the present Invention the request for data concerns data from 
30 more than one separate data sources (e.g. 2 unrelated web servers) can be combined 
to form the source date, which is then adapted to the mobile device/browser 
requesting the content. 

According to another aspect the present invention relates to a system for wireless 
35 communication of data between an external content source and a mobile device with 
Internet capabilities and equipped with a browser, comprising a converter for inline 
conversion of data in a first format as output from the external content source into a 
second, device-specific format to be received by the device or for conversion of data 
in the second, device-specific format into data in the first format, said system 
40 comprising: 



- receiving means for receiving the data in the first format. 
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- a database for storing and retrieving a conversion scheme, 

- a converter for converting the data based on a conversion scheme comprised of at 
least the following two separated conversion steps: 

- converting the data from the first format into an intermediate, devlce- 
5 Independent format using content-specific selection rules, manually 

created for each application, relating the first format to the intermediate 
format. 

- converting the data in the intermediate format into a device-specific, 
second format using general rules relating the intermediate format to 

10 the device-specific, second format 

and transmitting means for transmitting the converted data 

The converter for inline conversion of data in a first format could be specifically 
adapted for conversion of WEB server data into a second format to be received by the 

15 device such as a mobile device or for conversion of data in the second format into 
data in the first format. The converter may be a processor adapted In a computer 
system of any kind, such as in a PC. The two data formats could be HTML and WML or 
any other formats adapted for the two platforms - the WEB server and the WAP 
device. Inline conversion means that the conversion takes place when a mobile device 

20 requests the content, so that the client receives information comprised in the actual 
WEB page and not information from the WEB page that has earlier been converted. 

According to a preferred embodiment of the invention the converter may comprise a 
computer database wherein output data generated in response to input data is 
25 controlled by an identifier of the WEB server data. The identification could be based on 
a user-defined relationship between a number of WEB pages and matching schemas 
comprising conversion rules for the WEB pages. When a WEB page owner decides to 
enable conversion of the WEB page into a WAP device compliant format such as WML 

30 The conversion rules may be grouped into the schemas e.g. based on various versions 
of the two formats e.g. various versions of HTML, XML or WML or they may be 
grouped based on the type of information being converted. 

According to a preferred embodiment of the invention the first format is HTML, XML or 
35 a XML compliant format and the second format is WML or a similar a WAP compliant 
format. If the WEB page is in HTML the HTML could preferably be pre-converted or 
pre-processed into XML and then the XML format could be converted into WML based 
on a two-step conversion process. 

40 Brief descripti n f the drawings 
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A preferred embodiment of the invention will now be described in details with 
reference to the drawing in which: 

Fig. 1 shows a functional diagram of a system server, 

5 

Fig. 2 shows a system Layout diagram as an example of how the server could be used 
to implement a three-stage transformation. 

Examples 

10 Example 1 

System for conversion of data formats for exchange of data between a WEB 
server and a WAP device. 

This system makes it quicker and less expensive than currently possible systems to 
15 publish HTML content in WAP device. By use of the system, any existing HTML content 
can be transformed to the WAP device's native format WML. Therefore virtually any 
service currently available on the Internet can be made available to WAP devices in a 
matter of a few hours or days. 

20 The system acts as a filtering proxy, meaning that it processes and alters all requests 
from the WAP device and alt responses from the HTML web server. No alterations are 
needed on the server as long as it is at least HTTP 1.0 compliant and as long as the 
WAP device is compliant it should be able to display the response given from the 
system (since it is fully compliant with the WAP standard as defined by the WAP 

25 forum). A general overview is shown in Fig.l. 

The functionality's of this system is shown in Fig.l. The steps may be grouped into 
several parts, whereby the first part is the request to the server software 1 which is 
usually an HTTP request, but which may also originate from other sources. Parameters 

30 2 are passed in as part of the request and can be used to decide what document to 
transform, etc. Currently the parameters are used to decide which source 
document(s) to retrieve and how to transform them (i.e. which transformation 
documents to use). Each transformation may additionally define custom parameters 
that should be passed to it in the request. The source document retrieval 3 can take 

35 documents from any external data source. Current implemented sources are through 
HTTP from another web server, and through local I/O from the file system, but might 
also include databases and other 3rd-party systems such as content management 
systems or any other external data format. The source document 4 must be in legal 
XML format, but for non-XML documents (such as HTML) there may be a pre 
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processor (not shown explicitly on the diagram), which converts the input into a legal 
XML document in some well-defined way. 

The server supports multiple sources within one request. The multiple sources 5 are 
5 combined into one XML document, which allows access to all the sources in one 
document. The combined document 6 is the input for the next process. The input 
document is either the combined source documents directly, or the output from a 
previous transformation process. It is transformed by transformation process 7. 

10 One example of such transformation process is to apply an XSL transformation style 
sheet document. The type of the transformation document 8 depends on the 
transformation process. Which document is used depends on both the configuration of 
the transformation process and the parameters in the request. One example of such a 
configuration is to use one request parameter to name a document in the file system. 

15 

Another example is to use the user agent name (part of the request) to decide what 
transformation to use. The transformation document storage is independent of the 
transformation process hence these documents may be stored in any preferred 
fashion, e.g. in a file system or a database. The output from the transformation 9 is 

20 either the final result or the input to another transformation process. The 

configuration decides whether there are more transformation processes 10. Each 
transformation process has its own unique configuration and behaves in a certain 
predefined way (e.g. one can transform based on a request selected transformation 
document and another one can transform based on the user agent name). Generally 

25 the transformation is at least a two step process where the first step is based an a 
developer-defined context-specific conversion rules resulting in an intermediate 
device-independent, standardized format and whereas the second step is based on 
general conversion rules resulting in a device-specific version of the requested 
content. The result is sent to the user agent as a response 11 to its request. 

30 

Example 2 

Implementation of a three-stage transformation of data 

35 Figure 2 shows a System Layout diagram as an example of how the server could be 
used to implement a three-stage transformation, where each stage is marked with I- 
III. Note that a preprocessor might be applied before any of the three conversion 
steps is applied. 

40 The first step of a three-stage transformation is an extraction of all relevant 

information into a document in device-independent, standardized format (usually a 
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specific XHTI^L format based on general XHTML format) using context-specific 
conversion rules defined by an application developer. Then that document is 
transformed in a general form in another markup language (for example WML, 
CHTML, HTML or XHTML) based on general conversion rules and finally that document 
5 is transformed into device-specific content adapted to the user agent (for example 
WML which is specifically adapted for the Nokia 7110 WAP browser, optimizing for Its 
display and working around its bugs). The third step is also, generally, based on 
general conversion rules. 

10 Individual steps in the Layout diagram have the following function: 

The HTML source 12 may be anywhere, for example on an HTTP web server. The 
HTML document 13 is transmitted as-is. Note that HTML documents are not legal XML 
documents. The HTML document is converted to legal XML 14 before being presented 
to the transformation 27 process. The input into the first stage of the transformation 

15 15 is an XML document composed of the XML inputs, which have no predefined 

document type. The first stage 16 of the transformation extracts relevant information 
from the source document. The output 17 from the first stage is a predefined XML 
format, for example XHTML, which contains the relevant information from the XML 
input source. The second stage 18 transforms 27 the output from the first stage into a 

20 specific markup language (not device-specific). An example of this would be 

transforming to WML. This step may be regarded as a markup language translation. 
The general ML 19 is a specific markup language (e.g. HTML, WML, CHTML, XHTML 
etc.), but not adapted to known implementation details of any specific device. The 
third stage 20 transforms 27 the general form of the markup language and adapts it 

25 the specific user agent (device) doing the request. An example of adaptation is to 
divide up text elements to fit in the user agent device screen, or to work around a 
flawed user agent ML implementation 21. The device-specific markup language 21 is a 
result, which has been adapted to the specific user agent doing the request. 

30 The user agent receives the output 22. Other sources 23 can be used to generate the 
XML content. Examples of such sources are databases, content management systems, 
file systems, etc. Which transformation document to use is determined by the user 
request 24 (e.g. by means of a request parameter)? Which transformation document 
to use is determined by the name of the user agent 25, 26 (there exists a mapping 

35 between user agent names and what transformation document to use)? The 

transformation document database might, for example, be a local file system or a 
database. The transformation process and the storage mechanism are mutually 
independent, hence the storage mechanism may be changed transparently. 

40 A system development tool 28 may be used to define transformations for the first 
stage. These transformations may also contain hints for the third-stage 
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transformations, but these hints are then necessarily dependent on that 
transformation. 
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